61장. AWS 데이터베이스 지형 한눈에 보기

이 장에서 말하고자 하는 것

지금까지 우리는 ECS 위에 컨테이너를 띄우고
S3로 정적 자원을 다루는 흐름까지 만들었다.

이제 데이터 계층에 진입한다.

AWS의 데이터베이스는 단 한 종류가 아니다.

• 관계형 DB (RDS / Aurora)
• NoSQL (DynamoDB)
• 인-메모리 캐시 (ElastiCache)
• 검색 (OpenSearch)
• 시계열 (Timestream)
• 그래프 (Neptune)
• 분석 (Redshift)

이 장은 그 지형을 한눈에 보고
어떤 워크로드에 무엇이 어울리는지 를 정리한다.

1. 가장 자주 쓰는 4가지

이 책의 척추에서는 다음 4개가 중심이다.

나머지 (Neptune, Timestream, Redshift 등) 는 특수 워크로드용이다.

2. 관계형이 어울리는 경우

정형 스키마 + 트랜잭션 + 조인이 자주 필요

• 주문 · 결제 · 회계
• 회원 정보
• 재고 / 송장

데이터 사이의 관계가 명확하고, “한 번에 여러 테이블을 일관성 있게 바꾼다” 가 필요하면 관계형

3. DynamoDB가 어울리는 경우

"이 키로 이 값" 형태의 단순 조회가 대부분
초당 수만 ~ 수십만 건
응답 시간 한 자릿수 ms

• 세션 / 토큰 저장소
• 게임 점수 / 리더보드
• 이벤트 로그 / 시계열에 가까운 데이터
• 카탈로그 / 추천 결과

조인이 적고 무한 확장이 필요하면 DynamoDB

4. ElastiCache (Redis) 가 어울리는 경우

초저지연 (마이크로초 수준)
일시적 데이터 OK

• 캐시 계층 (DB 앞단)
• 세션 저장
• Rate limit 카운터
• 실시간 랭킹

“잠깐 빠르게” 가 필요하면 Redis

5. 어떻게 고르는가 — 의사결정 트리

조인 · 트랜잭션 자주 필요?
  └─ Yes → 관계형 (RDS / Aurora)
  └─ No
      └─ 키로 단순 조회만?
          └─ Yes → DynamoDB
          └─ No
              └─ 전문 검색?
                  └─ Yes → OpenSearch
              └─ 시계열?
                  └─ Yes → Timestream
              └─ ...

캐시 / 일시 데이터?
  └─ Yes → ElastiCache

6. 서비스별 DB 분리 — MSA의 핵심 원칙

orders   → orders 전용 DB
users    → users 전용 DB
payments → payments 전용 DB

여러 서비스가 같은 DB를 공유하면

• 스키마 변경이 서로 깨진다
• 한 서비스 부하가 다른 서비스에 번진다
• 배포 속도가 묶인다

Database per Service — 70장에서 자세히 다룬다

7. 우리 서비스에서

[ECS Service: orders]    → RDS (PostgreSQL) — 트랜잭션·조인
[ECS Service: users]     → RDS (PostgreSQL)
[ECS Service: payments]  → RDS (PostgreSQL)
[ECS Service: catalog]   → DynamoDB — 무제한 조회
[ECS Service: sessions]  → ElastiCache (Redis)

이렇게 한 서비스의 DB가 다른 서비스의 부담이 되지 않는다.

8. 직접 확인해보기 — CLI

# RDS
aws rds describe-db-instances

# DynamoDB
aws dynamodb list-tables

# ElastiCache
aws elasticache describe-cache-clusters

각자의 인터페이스가 다르다 — 데이터 모델이 다르기 때문이다.

9. 코드로는 이렇게 생겼다 — Terraform (개요)

# 관계형
resource "aws_db_instance" "orders" {
  identifier     = "orders"
  engine         = "postgres"
  engine_version = "16"
  instance_class = "db.t4g.small"
}

# NoSQL
resource "aws_dynamodb_table" "catalog" {
  name         = "catalog"
  hash_key     = "id"
  billing_mode = "PAY_PER_REQUEST"

  attribute {
    name = "id"
    type = "S"
  }
}

# 캐시
resource "aws_elasticache_cluster" "sessions" {
  cluster_id      = "sessions"
  engine          = "redis"
  node_type       = "cache.t4g.small"
  num_cache_nodes = 1
}

각자 다음 장들에서 자세히 본다.

10. 이렇게 쓰면 망한다 — 안티패턴

안티패턴 1. “RDS 하나로 다 한다”

서비스가 늘면 한 RDS가 병목이 된다.

서비스별로 DB를 분리한다

안티패턴 2. DynamoDB에 SQL식 사고방식을 그대로 적용

조인 · 임의 쿼리 · 복잡한 필터를 기대한다.
DynamoDB는 다른 사고방식이 필요하다 (66~68장).

안티패턴 3. 캐시를 영구 저장소처럼 쓴다

Redis 노드가 죽으면 데이터가 사라질 수 있다.

캐시는 캐시일 뿐 — 원본은 DB

안티패턴 4. 모든 워크로드에 같은 DB를 강요한다

“우리는 PostgreSQL만 쓴다” 같은 정책은 빠르게 한계에 부딪힌다.

워크로드에 맞는 DB를 고르는 게 운영 비용을 낮춘다

11. 한 줄로 정리

AWS 데이터베이스 지형은 한 종류가 아니며,
워크로드에 맞는 DB를 골라 서비스별로 분리하는 게 MSA의 토대다

12. 이 장의 핵심 정리

1. 자주 쓰는 4가지: RDS · DynamoDB · ElastiCache · OpenSearch.
2. 조인·트랜잭션 → 관계형 / 단순 조회·무제한 확장 → DynamoDB.
3. 초저지연·일시 데이터 → ElastiCache.
4. MSA에서는 Database per Service 가 원칙이다.
5. 워크로드마다 다른 DB를 쓰는 게 운영적으로 자연스럽다.